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Smart Card Application Development System and Method 



TECHNICAL FIELD 

5 This invention relates to a class of devices commonly known as smart cards 

and, in particular, to an application development system and method for smart 
cards. _ _ - - 

BACKGROUND OF THE INVENTION 

10 Today there is increasing use of "smart cards" in place of, or in addition to, 

conventional magnetic stripe cards ("mag cards"). A "smart card" is a thin card 
embedded with a memory device (volatile and/or non-volatile) and associated 
programmable or non-programmable logic. Unlike the mag card that merely stores 
"static" information (e.g., a credit card account number), a smart card, can add, 
1 5 delete and otherwise manipulate information stored on the card. Accordingly, smart 
cards are capable of storing and executing applications to carry out one or more 
functions within a smart card. 

While the physical dimensions and processing features of the smart card give 
rise to potentially limitless applications, die reality is that smart card applications 
20 are only being developed for large scale markets, e.g., banking, security and 
transportation applications. One reason for this limited growth lies in the cost 
associated with smart card application development. There are several reasons why 
smart card application development is a costly undertaking, not the least of which is 
the "closed" nature of the smart card, and the limited processing, memory and 
25 input/output resources of the smart card. 
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A smart card is often referred to as a ''closed" system because, for security 
purposes, a smart card is purposefully designed to not expose its memory, 

'intermediate-system-states-or-data-and-:address-bus-information4o-extemal-devices.- 

To do so would render it susceptible to unauthorized access (hacking) and fraud. 
5 While its closed nature is useful for secure applications such as banking 

transactions, ij_makes iLdifficult_to_ utilize prior art smart cards for devejopment 

purposes. It is to be appreciated that application development often requires access 
to memory or bus values, or system state information during intemiediate 
processing steps, access that has been specifically designed out of the smart card. 
10 Another encumbrance to the smart card application designer is the limited 

resources of the smart card. That is, due to the physical and processing constraints 
placed on the smart card, prior art smart cards do not enjoy any dedicated debug 
' facilities. Aside from the limited processing and memory attributes of a smart card, 
a smart card typically has but a single, bi-directional input/output (I/O) port. The 
15 communication bandwidth of this single I/O port is typically consumed to support 
execution of the smart card application itself, leaving little to no communication 
bandwidth to support debug features. Thus, application development using a smart 
card itself is virtually impossible. Consequently the development of applications 
for a smart card currently requires the use of an in-circuit emulator (ICE) and an 
20 associated, often proprietary software development application, 

An ICE system is typically comprised of a printed circuit card coupled to a 
computer system executing a proprietary software development application 
associated with the printed circuit card (emulator). The printed circuit card is 
designed to emulate the functionality of the smart card, while providing additional 
25 debug facilities (e.g., VO ports, memory buffers, address and data lines and the 
like), thereby providing the developer with the necessary access to adequately 
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debug their applications in development. One limitation of such smart card 
development systems is that the ICE and proprietary development application are 
chip=specific—Tliusran-emulator-for smart-card -employing-a-Siemens- pro 
will not work with an emulator employing a Philips or Motorola processor without 
5 significant hardware modification. Moreover, the software development 

application executing .on-.the_ computer _system_ is_ also _chip_-specific,. with _an. 

associated chip-specific compiler, linker and debugger, and often require that a 
developer learn the "programming language" of the development tool. 
Consequently, an application developed on one ICE system cannot be utilized (or 
10 directly ported to) a smart card employing a different processor without costly 
modification. 

These emulators work with special versions of the smart card processors 
called *bondouts' - thisse are the same processors as in the smart card but they 
expose their memory, data bus, etc to facilitate debugging. Since these special 

15 processors behave exactly like the processor in the smart card, many smart card 
processor manufacturers consider them to be a high risk items that may allow 
hackers to leam the smart card processor's deficiencies. To prevent this they screen 
recipients and make them sign restrictive agreements before these bondouts can be 
supplied. This model of working is totally unsuitable for the large scale acceptance 

20 and use by existing PC developer community. 

As a result of each of the foregoing limitations, smart card application 
development is a costly undertaking, typically performed by the large corporations 
that stand to profit from the sale of millions of smart cards. History has shown that, 
in order for a new technology to blossom, "grass roots" application development is 

25 required. That is, a technology will not truly become a pervasive technology unless 
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and until it is infused with the vitality and creativity of individual programmers and 
small development companies. 

■ Thus,-an-improved-application-jlevelopment-enviromnent-is-required-for- 

smart card applications that is unencumbered by the limitations commonly 
5 associated with the prior art. One such solution is presented below. 



SUIVIMARY OF THE TNVFNTmN 

niis invention concerns an integrated circuit (IC) card, such as a smart card 
and. more particularly, an improved application development system for smart card 
10 applications. In accordance with a first aspect of the invention, a smart card 
includes a smart card development interface (SCDI) to receive remote procedure 
calls from a computer system to application program interface (API) features of the 
smart card operating system, to invoke.^e API called in the received RPC. and tb 
respond to the computer system as qjpropriate. 
15 According to another aspect of the invention, a computer system includes an 

innovative client development interface (CDI), to marshal and issue a remote 
procedure call to an associated API of the operating system of the smart card, and to 
receive and present a response from the smart card for presentation to a calling 
application, as appropriate. 
20 It is to be appreciated that combination of the foregoing aspects of the 

present invention gives rise to a smart card application development system 
comprising a computer system endowed with the client development interface 
(CDI). and a smart card incorporating the smart card development interface, 
wherein the computer system is executing a common development application that 
25 issues commands to smart card API's, whereupon the CDI intercepts the remote 
procedure calls, marshals the parameters associated with the command and issues 
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the command to the smart card. The developmeni interface of the smart card 
receives and un-marshals the command and invokes an API. called by the RFC, 

"""shaling-and-issuing-a-response-to-the-computer-system-as-appropriater-A 
development system incorporating these innovative aspects facilitates smart card 
5 development without the need for an ICE system, typical of the prior art. Thus, the 

present invention represents a new_paradigm.in smart card application development,. 

enabling entry into the market of individual programmers and small development 
companies. 

10 BRIEF DESC RIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of an example smart card application development 
system including a computer system and a smart card; 

Fig. 2 is a block diagram of an example computer system including an 
innovative client development interface, -suitable for use in the smart card 
1 5 application development system of Fig. 1 ; 

Fig. 3 is a block diagram of an example client development interface suitable 
for use within the computer system of Fig. 2; 

Fig. 4 is a block diagram of an example smart card including a smart card 
development interface, suitable for use in the smart card application development 
20 systeniofFig. 1; 

Fig. 5 is a block diagram of an example smart card development interface, 
suitable for use within the smart card of Fig. 4; 

Fig. 6 is a graphical illustration of a data structure containing an example 
proxy library suitable for use in the computer system of Fig. 3; 
25 Fig. 7 is a graphical representation of an example marshaling buffer suitable 

for use with the present invention; 
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Fig. 8 is a' graphical representation of an Example unmarshaling buffer 
suitable for use with the present invention; and 

^'g- ^ aJlow_chart of an exam ple method for smart card ^ir^ 



development utilizing the innovative smart card application development, system 
5 depicted in Fig. 1. 

PETAILEDBESCMPTTQNOF THEPREIirRRFDEMBODT^^ 
Example Development System 

Fig. 1 illustrates a smart card application development system 100 
10 comprising a computer system 102 employing a generic software development 
application coupled to a smart card 104. The exemplary development system 100 
of Fig. 1 depicts computer system 102 coupled to smart card 104 via a card reader 
106 and a communication medium 108. Tlie communication medium 108 is 
intended to represent any of a number of typical commmiication links including, but 
15 not limited to, a proprietary data bus, an industry standard data bus, a local area 
network (LAN), a wide area network (WAN), or a global area network (e.g., the 
Internet). In this regard, the innovative smart card application development system 
100 facilitates remote development of smart card applications using an actual smart 
card 104 coupled to a remote computer system 102 via a communications network 
20 108 and a card reader 106. 

According to one aspect of the present invention, smart card 104 comprises a 
smart card development interface 1 1 0 coupled to an operating system (OS) 1 12 with 
a set of innovative smart card application program interfaces (APIs). It is to be 
appreciated that the APIs provide a wide range of functional capability within the 
25 smart card, albeit limited to the application area suitable for smart cards . As will 
be developed in greater detail below, the smart card development interface (SCDI) 



wo 00/68903 

.PCT/USOO/12933 



7 

110 receives remote . procedure calls (RPC) from computer system 102 and 
selectively invokes APIs associated with operating system 1 12 enabling smart card 
ip4jo_ca]Ty. out_specifi£_to^^^^ 



innovative smart card 104 is controlled in a step-wise fashion that is conducive to 
5 application development. It is to be appreciated that, but for the smart card 
-. _ _.^^^^°P™^t i"terfa':e (SCDl) 1% smart card J 04_andjts_op_erating. system. wiA 
associated API's 1 12 is intended to represent any of a broad range of integrated 
circuit cards and their operating systems commonly known in the art. That is, any 
smart card endowed with the smart card development interface 1 10 is suitable for 
1 0 use within the smart card application development system 1 00 of Fig. 1 . 

It is noted that, in addition to the illustrated smart cards, the IC card might be 
embodied in other forms, such as an electronic wallet, a personal digital assistant, a 
smart diskette (i.e., an IC-based device having a form factor and memory drive 
interface to enable insertion into a floppy disk drive), a PC card (formerly PCMCIA 
15 card), and the like. Generally, the integrated circuit card 104 is characterized as an 
electronic device with hmited processing capabilities and memory wherein large 
size number crunching is either absent or is provided for specific security purposes 
(e.g.. to execiite cryptographic algorithms). For purposes of this discussion and 
within the context of the illustrated implementation, the terms "IC device", "IC 
20 card", and "smart card" will be used interchangeably to reference the smart card 



104. 



Card reader 106 provides a necessary interface between smart card reader 
104 and a computing system such as, e.g., computer system 102. Card readers are 
typically designed to support any of a number of standardized communication 
25 protocols supported within the smart card community and, in this way, can typically 
accommodate smart cards adhering to any of the recognized communication 
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standard from any smart card manufacturer. In this regard, card reader 106 is 
typically not chip- or card-specific ahhough in some cases it may be. For purposes 
_ of this dis cus sion, card reader 106 inclu des the nece ssary hardware an d software 
resources required to support standardized communication between computer 102 
5 and smart card 104. Consequently, card reader 106 is merely intended to be 
illustrative of card readers typically known within the art. 

Computer system 102 is depicted within Fig,. 1 as comprising an innovative 
client development interface (CDI) 114, a plurality of executable applications 116 
including a development application 118, each of which is supported by the 
10 resources of a typical operating system 120, as shown. As will be developed in 
more detail below, the client development interface (CDI) 114 identifies remote 
procedure calls (RPCs) to smart card 104 resources (e.g., API's), marshals the 
, parameters required by the smart card 104 and issues the RPC to the smart card 
development interface 110 via communication channel 108 and card reader 106. 
15 The smart card 104 receives and executes the called API and returns the result to 
the calling apphcation via the communication channel 108 and CDI 114, as 
appropriate. But for the cHent development interface 114, computer system 102, 
applications 116 and operating system 120 are each intended to represent any of a 
number of commonly known computer systems, applications and operating systems, 
20 respectively, known in the art. 

According to one aspect of the present invention, any of a number of prior 
ah development applications, or tools, may well be used in accordance with the 
innovative SCDI 110 and CDI 114 of development system 100 to develop smart 
card applications. Examples of such software development tools include Visual 
25 Basic or Visual C/C++ from Microsoft Corporation of Redmond, WA. Thus, a 
smart card application is developed using computer 102 and a typical software 
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development tool 118, utilizing smart card API calls within the developed code. 
The smart card API's are recognized by client development interface 114, described 

above , which selectiv ely i nvokes the called resource s of the smart rarHjIfp 

In this regard, development system 100 comprising an innovative SCDI 110 
5 and a CDI 114 effectively liberates a developer from the costly and cumbersome 

proprietaiy development tools commonly associated with the prior art.. Rather the 

present invention facilitates application development using a standard personal 
computer 102 endowed with typical software development tools and an innovative 
client development interface 114 can develop smart card applications using smart 
1 0 card 1 04 endowed with a smart card development interface 110. 

Example Computer System 

in the discussion herein, the invention is described in the general context of 
computer-executable instructions, such as program modules, being executed by one 

15 or more conventional computers. Generally, program modules include routines, 
programs, objects, components, data structures, etc. that perform particular tasks or 
implement particular abstract data types. Moreover, those skilled in the art will 
appreciate that the invention may be practiced with other computer system 
configurations, including hand-held devices, personal digital assistants, 

50 multiprocessor systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe computers, and the like. In a 
distributed computer environment, program modules may be located in both local 
and remote memory storage devices. 

Fig. 2 shows a general example of a computer system 102 incorporating the 

5 teachings of one aspect of the present invention, and suitable for use within the 
smart card application development system 100. It will be evident, from the 
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discussion to follow, thiat computer 102 is intended to represent any of a class of 
general or special purpose computing platforms which, when endowed with the 
innovative client development inte rface, is suitable for use in sm ar t card a p plication 
development system 100. In this regard, the following description of computer 
5 system 102 is intended to be merely illustrative, as computer systems of greater or 
lesser capability may well be substituted without deviating from the spirit and scope 
of the present invention. 

As shown, computer 102 includes one or more processors or processing units 
132, a system memory 134, and a bus 136 that couples various system components 
10 including the system memory 134 to processors 132. 

The bus 136 represents one or more of any of several types of bus structures, 
including a memory bus or memory controller, a peripheral bus, an accelerated 
graphics port^ and a processor or local bus using any of a variety of bus 
architectures. The system memory includes read only memory (ROM) 138 and 
15 random access memory (RAM) 140. A basic input/output system (BIOS) 142, 
containing the basic routines that help to transfer information between elements 
within computer 102, such as during start-up, is stored in ROM 138. Computer 102 
further includes a hard disk drive 144 for reading from and writing to a hard disk, 
not shown, a magnetic disk drive 146 for reading from and writing to a removable 
20 magnetic disk 148, and an optical disk drive 150 for reading from or writing to a 
removable optical disk 152 such as a CD ROM, DVD ROM or other such optical 
' media. The hard disk drive 144, magnetic disk drive 146, and. optical disk drive 
150 are connected to the bus 136 by a SCSI interface. 154 or some other suitable bus 
interface. The drives and their associated computer-readable media provide 
25 nonvolatile storage of computer readable instructions, data structures, program 
modules and other data for computer 102. Although the exemplary environment 
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described herein employs a hard disk 144, a removable magnetic disk 148 and a 
removable optical disk 152, it should be appreciated by those skilled in the art that 

■ other-types-oCcomputer-readable-media-which-Gan-store-data-lhat-is accessible by-^^ 

computer, such as magnetic cassettes, flash memory cards, digital video disks, 
5 random access memories (RAMs) read only memories (ROM), and the like, may 

_also,bejised in^the_exempIary_ope^^ _ 

A number of program modules may be stored on the hard disk 1 44, magnetic 
disk 148, optical disk 152, ROM 138, or RAM 140, including an operating system 
158, one or more application programs 160 including, for example, the innovative 
10 client development interface 114, other program modules 162, and program data 
164. A user may enter commands and information into computer 102 through input 
devices such as keyboard 166 and pointing device 168. Other input devices (not 
shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the 
like. These and other input devices are connected to the processing unit 132 
15 through an interface 170 that is coupled to bus 136. A monitor 172 or other type of 
display device is also connected to the bus 136"via an interface, such as a video 
adapter 174. In addition to the monitor 172, personal computers often include other , 
peripheral output devices (not shown) such as speakers and printers. 

As shown, computer 102 operates in a networked environment using logical 
20 connections to one or more remote computers, such as a remote computer 1 76. The 
remote computer 176 may be another personal computer, a personal digital 
assistant, a server, a router or other network device, a network "thin-client" PC, a 
peer device or other common network node, and typically includes many or all of 
the elements described above relative to computer 102, although only a memory 
25 storage device 1 78 has been illustrated in Fig. 2. 
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As shown, the logical connections depicted in Fig. 2 include a local area 
network (LAN) 180 and a wide area network (WAN) 182. Such networking 

«"V'fP'™ents-are-commonplace-in-offiGes-enterprise-wide-Gomputer-netwGrks, 

intranets, and the Internet. In one embodiment, remote computer 176 executes an 
5 Internet Web browser program such as the "Internet Explorer" Web browser 
- _ manufaciured and_distributed by MicrpsofLCorporation_of Redmond, _Washington_ 
to access and utilize online services. 

When used in a LAN networking environment, computer 1 02 is connected to 
the local network 180 through a network interface or adapter 184. When used in a 
10 WAN networking environment, computer 102 typically includes a modem 186 or 
other means for establishing communications over the wide area network 182, such 
as the internet. The modem 1 86, which may be internal or external, is connected to 
the bus 136 via a serial port interface 156. Iii a networked environment, program 
modules depicted relative to the personal computer 102, or portions thereof, may be 
1 5 stored in the remote memory storage device. It will be appreciated that the network 
connections shown are exemplary and other means of establishing a 
communications link between the computers may be used. 

Generally, the data processors of computer 102 are programmed by means of 
instructions stored at different times in the various computer-readable storage media 
20 of the computer. Programs and operating systems are typically disfributed, for 
example, on floppy disks or CD-ROMs. From there, they are installed or loaded 
into the secondary memory of a computer. At execution, they are loaded at least 
partially into the computer's primary electronic memory. The invention described 
herein includes these and other various types of computer-readable storage media 
25 when such media contain insthictions or programs for implementing the innovative 
steps described below in conjunction with a microprocessor or other data processor. 



wo 00/68903 



PCT/USOO/12933 



13 

The invention also includes the computer itself when programmed according to the 
methods and techniques described below. Furthermpre, certain sub-components of 

*e-computer-may-be programmed-fo-perfonn-the-functions-and-steps-described 
below. The invention includes such sub-components when they are programmed as 
5 described. In addition, the invention described herein includes data structures, 

- - - described below, as-embodied on- various types-of-memory media.. . 

For purposes of illustration, programs and other executable program 
components such as the operating system are illustrated herein as discrete blocks, 
although it is recognized that such programs and components reside at various times 
10 in different storage components of the computer, and are executed by the data 
processor(s) of the computer. 



Example Client Development Interface 

Fig. 3 illustrates a block diagram of an example client development interface 
15 114, suitable for use in computer system 102. As shown, client development 
interface 114 comprises control logic 302, an application program interface proxy 
library 304 and one or more marshaling/un-marshaling buffers 306, each coupled as 
depicted. According to this implementation, client development interface 114 is 
invoked by a calling application. Thus, in order to utilize the resources of CDI 1 14 
20 and, more specifically, the proxy library 304, the CDI 1 14 must be identified widiin 
the executing application. In one embodiment, this is done by identifying the 
resource in the code of the application. 

Control logic 302 is intended to represent any of a broad range of logic 
known in the art. In one implementation, control logic 302 is a processor, while in 
25 alternate embodiments control logic is a microcontroller, a programmable logic 
array, or a series of executable instructions which perform logic functions. Control 
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logic 302 communicates with smart card 104 in any of a plurality of standard smart 
card communication protocols. In alternate embodiments, non-standard protocols 
-may-well-be used-to-communicate-between-controller-302-and-smart-card-1.04-such 



as, for example, a unique development communication protocol. Although not 
5 specifically denoted, it is to be appreciated that controller 302 communicates with 

smart c_ard L04,_and any other penph_eral.for_that n^attej, jdajhejjommjmJcAtion. 

resources of operating system 120. Insofar as such resources are well known in the 
art, they need not be described flirthCT here. 

As used herein, "marshaling" means converting a function argument from its 
10 binary representation (i.e., compiled application format) into some language- 
independent foimat, and then converting this generic representation into a binary 
format appropriate to the called function, (i.e., that of the smart card). Accordingly, 
the marshaling/unmarshaling buffer(s) 306 are one or more buffers wherein the 
parameters necessary to issue a complete API call, as defined by the proxy library, 
15 are compiled before issuance to the SCDI 1 10 of the smart card 104. Accordingly, 
marshaling/un-marshaling buffer(s) 306 are intended to represent any of a number 
of alternate memory devices commonly known to those in the art. 

TTie application program interface proxy library 304 provides a functional 
library of smart card application program interfaces available to a calling 
20 application. Accordmg to one implementation, proxy library 304 contains a 
detailed listing of all smart card API's, associated function calls and function 
parameters, necessary to invoke the API on smart card 104. As will be developed in 
more detail below, upon recognizing a call to a smart card API, control logic 302 of 
CDI 114 accesses proxy library 304 to identify the associated function call and 
25 required parameters necessary to property invoke the function on the smart card 
104. Control logic 302 establishes a buffer entry within marshaling/un-marshaling 
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buffer(s) 306 in which to marshal (or compile) the necessary parameters. Once the 
necessary parameters have been collected (marshaled), control logic 302 issues a 
command to the smart card JOj^via^networ k 108 and ca rd reader 106 using a smart 
card standard communication protocol such as, for example. International Standards 
5 Organisation (ISO) 7816 T=0, or T=L 

Although depicted as a separate functional element, those skilled in the art 

will appreciate that client development interface 1 14 may well be integrated within 
and utilize the control features associated with the software development 
application 118. In one implementation, for example, control logic 302 and the 
10 marshaling/un-marshaling buffer(s) 306 may well be supplied by a debug 
environment within the application development tool 118, wherein chent 
development interface is comprised solely of proxy library 304. Accordingly, the 
. teachings of the present invention may well be practiced with variation from the 
exemplary embodiment without deviating from the spirit and scope of the present 
15 invention. 

Application Program Interface 

Those skilled in the art will appreciate that an application program interface, 
or API, interfaces a (usually) higher-level program such as an application to lower- 

20 level services and functions of another application or resource. In this regard, the 
API provides an "abstraction layer" to the functions and services of another 
resource. According to one aspect of the present invention, proxy library 304 
provides a number of innovative IC card API's that enable a developer to write and 
test smart card applications on a host computer system (102) using the functional 

25 resources of a communicatively coupled IC card ( 104). 
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According to this aspect, the application running on the host can use the 
remote procedure call (RPC) method, introduced above, to access the APIs on the 
card. The API calls injucL^Qgrams_areJdentified_by.xontrol Jogic-302-of_C^^^ 



1 14 and proxied to SCDI 1 10 of theIC card 104 via marshaling buffer 306. The 
5 API itself is thus executed on the card 104 and the results are sent back to the 
- . _ application executmg_on computer J 02 via SCDIJ 10, comm_unjcatjonj:hannd 1 08_ 
and CDI 114, respectively. As alluded to above, to utilize CDI 114 and proxy 
library 304, applications need to include a header file and'link to the proxy library. 
In one implementation, the header file is the "wincard-proxyH" header file and the 
10 scwapi.dll API library. After referencing such files in the header, a call to a smart 
card resource will be in the form: 

SCODE WINAPI API Gall (API arguments) (i) 

15 For purposes of illustration, and not limitation, some example API's are presented 
m Table I, below, that enable an application executing on a computer system ,(102) 
to utilize the functional resources of a communicatively coupled IC card (104), 
according to the teachings of the present invention. A more complete description of 
these and additional innovative APIs are provided in Appendix A. 



20 



Function Call 


Description 


ScwAttachToCard 


A prerequisite for all other RPC API calls; used to 
connect with the card and initialize internal data 
structures that are needed for other API calls. 


ScwDetachFromCard 


Frees the resources of an identified IC card; this 
API should always be called at the end of an RPC 
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session. 


ScwCreateFile 


Enables an application executing on a computer to 
_open_an_e)cisting_file_residing.QnJhe_IC_card, or to 




create one if it does not already exist. 


ScwDeleteFile 


Enables an application executing on a computer to 
delete the indicated file, which could be an access- 
control list (ACL) or a directory. 


ScwWriteFileByName 


Enables an application to write to an IC card file at 
an indicated offset without having to open the file. 


ScwReadFileByName 


Enables an application to read from an IC card file 
at an indicated offset without having to open the 
file. 


ScwIsAuthenticated 


Enables an application to invoke an authentication 
function on the IC card. 



Table I: Example IC Card APIs 



It will be appreciated that the RPC development environment facilitated by the 
innovative APIs, SCDI 110 and GDI 114 execute with all of the speed and 
resources of the host computer, while eliminating the need to "emulate" the smart 
card resources - an actual smart card is utilized instead. 

Example Smart Card 

Fig. 4 illustrates a block diagram of an example smart card 104 suitable for 
use within sman card application development system 100 of Fig. 1. In addition to 
the innovative smart card development interface (SCDI) 110 and an operating 
system with associated APIs 112, smart card 104 is shown comprising an 
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input/output interface 402, a plurality of applications 404 including smart card 
development interface 110, memory 406 and control logic 408. As discussed 

above, exce pt for th e inclusion of innovative s mart card Hevplnpmpnt i^t^rfa^p 

(SCDI) 110, to be described more fully below, smart card 104 is intended to 
5 represent any of a broad category of integrated circuit (IQ cards commonly known 
_ . . J" art. Thus, but for SCpi IJO, each ofI/0 402,^pplications 404, manory_4q6 
and control logic 408 are likewise commonly known within the art and, 
consequently, will not be fiirther described here. 

Fig. 5 illustrates a block diagram of an example smart card development 
10 interface (SCDI) 110, suitable for use within smart card 104 of application 
development system 1 00 in Fig. 1 . In accordance with the example implementation 
of Fig. 5, SCDI 1 10 is shown comprising control logic 502 and marshaling/un- 
marshaling bufrer(s) 504, coupled as depicted. According to one implementation, 
SCDI 1 10 is invoked by CDI 114 upon the initial remote procedure call to smart 
15 card 104. 

According to this exemplary implementation, control logic 502 may be any 
of a plurality of logic and logic functions commonly known in the art such as, for 
example, a processor, a controller, or a plurality of executable instructions which 
implement such functionality. Control logic 502 receives a function call from CDI 

20 114 via communication channel 108, card reader 106 and smart card I/O 402 
according to any of a plurality of communication protocols, described above. In 
response, control logic 502 invokes the called API, utilizing the parameters 
received in the marshaled function call. Smart card 104 executes the called API. If 
a response is called for by the executing API, control logic 502 establishes a buffer 

25 entry within marshaling/un-marshaling bufrer(s) 504 and, once marshaled, issues 
the response to the CDI 114 via smart card I/O 402, card reader 106 and 
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communication channel 108. Accordingly, control logic 502 receives and interprets 
the remote procedure calls from the CDI 114 to selectively invoke called API's of 
-the_smart_card_OS_LL2,_and-to^retum-response-inforraation-to-CDI-U4-as- 



appropriate. 

5 As described above, SCDI 1 10 is responsive to the application development 

interface of an appropriately endowed, computer_system, e^g.,. computer, 102, to 

convert the otherwise ordinary smart card 104 into an essential development, tool. 
No longer does a developer have to rely on emulation or simulation of smart card 
resources, but rather, the SCDI 110 opens the otherwise closed resources of the 
10 smart card 104 to the developer. 

Example Data Structure.^ 

Fig. 6 is a graphical illustration of a data sti^cture containing an example 
proxy library 600, suitable for use by computer system 1 02 of development system 

15 100 of Fig. 1 . As shown, proxy library 600 contains a list of remote procedure calls 
602 corresponding to smart card application program interface (API) function codes 
604. In addition, proxy library 600 includes fields for the size 606 of the function 
call, the number of parameters 608. the parameter type 610 and whether invocation 
of the function call elicits a response 612. 

20 Fig. 7 is a graphical representation of an example send buffer suitable for 

use in association with the present invention. As shown, send (or marshalling) 
buffer 306 provides enough fields to accommodate elemental aspects of a smart 
card communication protocol. In accordance with the illustrated example 
embodiment of Fig. 7, marshaling buffer 306 is established by control logic 302 

25 with fields 702 in accordance, with the International Standards Organisation 
standard 7816 (ISO 7816) communication protocol command structure. As 
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described above, the marshaling buffer 306 is populated with information retrieved 
from proxy library 600. 

F ig. 8 is a graphical illustrat ion of an example res ponse buffer suitable for 



use in association with the present invention. As shown, response buffer 504 
5 provides enough fields to accommodate the elemental aspects of a smart card 
^communication protocol. In accordance with the illustrated example embodiment 
of Fig. 8, response buffer 504 is established by control logic 502 to include a^ 
data_field, and two status byte fields (SWl, SW2), cumulatively referenced as 802. 
It is to be appreciated that although proxy library 600 is depicted as a two- 
10 dimensional data structure, this is for ease of explanation only. Data strucnires of 
greater or lesser complexity are anticipated within the scope of the present 
invention. 



15 



Example Op crarinn 

Fig. 9 is a flow chart of an example method for smart card application 
development utilizing the innovative smart card application development system 
depicted in Fig. 1. For ease of explanation, and not limitation, the method of Fig.9 
will be developed with continued reference to Fig. 's 1 -8. 

With reference to Fig. 9, the method begins with step 902 wherein a 
20 developer writes a smart card application in any of a number of alternative 
languages and/or common application development tools, specifying a smart card 
proxy library and embedding remote procedure calls to smart card API's within the 
code of the application. As described above, the software development application 
118 is immaterial, so long as the smart card proxy library is specified within 
25 application.' CDI 110 will be invoked when the host computer 102 executing the 
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application processes an RPC to a smart card API. In step 904, the application is 
invoked. 

^"-step-906,.the-application-executes-imtil-a-remote-procedure-caU_(RP.C)_to 

an IC card API is encountered. In step 908, upon detecting a smart card RPC, 
5 control logic 302 of CDI 1 14 accesses proxy library 304 to identify the functions 

_and paj;amMers_associajed whh_the RPC and establishes a^ buffer enfry within. 

marshaling buffer 306 to compile the required parameters. The control logic 302 
prepares the buffer entry (also referred to, as the send buffer) in marshaling buffer 
306. To further explain this point, consider the example API call and the example 
10 proxy library of Fig. 6. 

As described above,, the information contained in the proxy library 600 
enables CDI 106 to create a marshaling (or, send) buffer (306) to generate the API 
call to the smart card. In accordance v/ith the illustrated example of Fig. 6, the 
"ScwIsAuthenticated remote procedure call 614 is depicted, widi associated 
15 inforaiation in corresponding fields 604-612. Accordingly, upon receiving the 
ScwIsAuthenticated RPC 614, CDI 106 creates a marshaling buffer 306 according 
to the information retrieved from the proxy library 600 to marshal the information 
required for transmission to the smart card. An example of the send buffer for the 
ScwIsAuthenticated is illustrated with reference to Fig. 7. It is to be appreciated 
20 that different RPC's of greater or lesser complexity may have associated send- 
buffers with a corresponding greater or lesser complexity. Appendix A includes a 
listing of innovative remote procedure calls and their associated send-buffer's, 
according to one aspect of the present invention. 

In step 910, the completed send-buffer is sent to sman card 104 via 
25 communication channel 108 and card reader 106, and CDI 1 14 awaits a response 
from the smart card, as appropriate. 
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In step 912, control logic 502 of smart card development interface 110 receives the 
send buffer via I/O port 402 and invokes a corresponding application program 

•"»erface-(-AJ^I-)^establishing-a-response-bufferin-buffer(i)-5G4rasr^^^^ 

step 914, upon completion of the API command at smart card 104, control logic 502 
5 of smart card development interface 110 marshals response parameters in response 
. _ buffer 504. according Lo definition of the.calLed_API,_an.d. sends the response buffer 
to the GDI 1 14 via I/O port 402, card reader 106 and communication channel 108. 
^ In accordance with the illustrated example embodiment, an exarnple response buffer 
504 is graphically illustrated with reference to Fig. 8. As above, the response buffer 
10 of Fig. 8 is for illustrative purposes, as response buffers of greater or lesser 
complexity coiresponding with API's of greater or lesser complexity are anticipated 
within the scope of the present invention. 

In step 916, upon i-eceiving a response buffer from SCDI 110, control logic 
302 of GDI 1 14 promotes the response to the calling application 1 1 8. 
5 It is to be appreciated that the innovatiye smart card development interface 

110 transforms the otherwise closed system of smart card 104 into an application 
development tool. Moreover, the client development interface 114 transforms a 
common application development tool such as Microsoft's Visual BASIC, or Visual 
■ C/C++ into a smart card application development tool. Accordingly, the 
) combination of the smart card development interface 110 and the client 
development interface 114 enable a developer to enter the smart card development 
market with minimal cost, thereby facilitating the development of applications for . 
limited-sized markets and promoting the growth of the smart card industry. 

Although the invention has been described in language specific to structural 
features and/or methodological steps, it is to be understood that the invention 
defined in the appended claims is not necessarily limited to the specific features or 
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Steps described. Rather, the specific features and steps are disclosed as preferred 
forms of implementing the claimed invention. 



5 
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CLAIMS 

^Aii-integraled-eirGuit-(IG)-Gard-cGniprising:- 

an input/output (I/O) interface; and 
5 . a smart card development interface, responsive to commands received via 
- _ _ _the I/O interface, to receive remoie procedure calls .(RPQJrom a computersystan^ 
executing an application under development within a development application and 
to invoke an application program interface (API) called in the RPC. 

' ^ 2. An integrated circuit (IC) card according to claim 1 , wherein the smart 

card development interface includes: 

a memory having stored therein a plurality of executable instructions; and 
control logic, coupled to the memory, to execute the plurality of executable 
instructions to implement a smart card development interface, wherein the smart 
1 5 card development interface receives and un-marshals a remote procedure call (RPC) 
from a remote computer system and invokes one of a plurality of application 
program interface(s) (API) corresponding to the received RPC. 

3. An IC card according to claim 2, wherein the control logic establishes 
20 a response buffer in an associated memory and marshals a response to the RPC 

based, at least in part, on the called API. 

4. An IC card according to claim 2, wherein the control logic receives the 
RPC from the remoie client computer via an removably coupled IC card interface, 

25 responsive to the remote computer 
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5. An IC card according to claim 2, further comprising a storage medium 
having stored thereon a plurality of executable instructions which, when executed, 
implement the smart card development interface. 



5 6. An IC card according to claim 2, wherein the called APFs are standard 

API's of the IC card operating system. 

7. An IC card according to claim 2, wherein the called API's are special 
development API's of the IC card operating system invoked only from a remote 

1 0 computer executing an associated application development program. 

8. An IC card according to claim 2, wherein the IC card receives the RPC 
according to any of a plurality of IC card communication standards. 

15 9. An IC card according to claim 2, wherein the IC card posts a response 

to the RPC in one of a plurality of IC card communication standards corresponding 
to the standard in which the RPC was received. 

10. An IC card according to claim 2, wherein the IC card receives RPC's 
20 from any of a number of remote computers communicatively coupled to the remote 
computers via a removably couplied IC card interface and a communication 
network. 



25 



11. A computer system comprising: 

a memory device having stored therein a plurality of instructions; 
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a processor, coupled to the memory device, to execute the plurality of 
instructions and implement a smart card application development tool within which 

sm art card a p plications are dev eloped with .remple_pro_c_ejd.ure^ call(s)_(RRC)_tQ 

application program interface(s) (API); and 
5 a client development interface, coupled to the memory device and the 

processor, responsjve to the execution of the RPCjo marshaUnd jssue a command 

to a smart card invoking an associated API. 

12. A computer system according to claim 11, wherein the client 
10 development interface comprises a proxy library containing smart card API 

information. 

13. A computer system according to claim 1 1, wherein the proxy library 
includes information regarding the smart card API's including a number and type of 

1 5 parameters associated with each smart card API. 

14. A computer system according to claim 11, wherein the smart card 
application development tool is a common software development application 
executing on the computer system. 

20 

15. A computer system according to claim 11, wherein the client 
development interface issues an API call to a smart card via a communication 
channel and a smart card interface. 
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16. A computer system according to claim 11, wherein the smart card 
interface is a common card reader. 



17. A computer system according to claim 11, wherein the client 
5 development interface issues an API call to the smart card according to any of a 
plurality of standard smart card communication protocols. 

18. A computer system according to claim 11, wherein the client 
development interface issues an API cal to the smart card according to a non-. 

1 0 standard smart card development protocoL 

19. A computer system according to claim 11, wherein the client 
development interface receives a response to an API call from the smart card, and 
posts the response to calling application. , 

15 

20. A computer system according to claim 19, wherein the calling 
application is the smart card application development tool. 

21. A computer system according to claim 19, wherein the calling 
20 application is an application under development within the smart card application 

development tool. 



25 



22. A smart card application development system comprising: 
a computer system having a smart card application development tool stored 
thereon; and 
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a smart card, responsive to the computer system, including a smart card 
development interface to receive remote procedure call(s) (RFC) to application 
program interface(s) ( API) associated with the smart c ard operating system from the 
smart card application development tool. 

. 5 ' 

23. A smart card application development system according to claim 22, 
wherein the computer systeni further comprises a client development interface, to 
receive and identify the smart card API associated with a particular RFC. 

10 24. A smart card application development system according to claim 23, 

wherein the client development interface includes a proxy library with information 
regarding each of a plurality of API calls, including a number and type of 
parameters required to make the API call. 

15 25. A smart card according to claim 24, wherein the client development 

interface receives an RPC and marshals the parameters identified in the proxy 
library before issuing the API call identified within the RPC. 

26. A smart card according to claim 24, wherein the client development 
20 interface identifies an API associated with an RPC call and issues the API call to 
the smart card. 
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27. A smart card development system according to claim 26, wherein the 
client development interface issues the API call to the smart card via a 

com munication channel an d a smart.car d interface according to any of a plurality of 

standard smart card communication protocols. 

5 

28. A smart card development system according to claim 22, wherein the 
smart card comprises a smart card development interface to receive API calls from 
the computer system and to invoke called APIs. 

10 29. A smart card development system according to claim 28, whierein the 

smart card development interface marshals response parameters to issue to the 
computer system, depending on a definition of the called API. 

30. A smart card development system according to claim 28, wherein the 
15 smart card development interface issues a response to the computer system in a 
select one. of a plurality of standard smart card communication protocols 
corresponding to the smart card communication protocol in which the API call was 
received. 

20 31. A smart card development system according to claim 22, wherein the 

smart card application development tool is a common software development 
application. 

32. A method for developing smart card applications comprising: 
25 writing software in any one of a plurality of common software development 

languages using a computer system; and 
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embedding within the software remote procedure calls (RPC) to one or more 
of a plurality of smart card application program interfaces (API) available within a 
' co u pled smart ca rd. 



5 33. A method for developing smart card apphcations comprising: 

'_ ^coupling a computer Jia\™g^ tiiereon an application 

development tool to a card reader with a removably coupled sman card; 

executing an application on the computer within the application 
development tool until a remote procedure call (RPC) to a smart card 
10 application program interface (API) is encountered within the appHcation; 

and 

assembling necessary parameters to issue a call to the API identified 
in the RPC and calling the API at the smart card via the card reader. 

34. A method for developing smart card applications according to claim 
33, wherein the application development tool is a common ^software development 
application. 

35. A method for developing smart card applications according to claim 
20 33, further comprising accessing a proxy library within the computer system, the 

proxy library including information regarding each of a plurality of smart card APIs 
including a number and type of necessary parameters required to invoke each of the 
smart card APIs 
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36, A method for developing smart card applications according to claim 
33, wherein the assembling step comprises marshaling necessary parameters for the 
ealled-API,-asdefinedJwithin-a.proxyJibraiy,jn,a_sei^^^ 

5 37. A method for developing smart card applications according to. claim 

36, fiirtheLConiprising issuing the sendjbuffer to the smart card when all necessary 

parameters have been marshaled. 

38. A method for developing smart card applications according to claim 
10 37, further comprising invoking the called API at the smart card upon receipt of the 
send buffer. 

39- A method for developing smart card applications according to claim 

38, further comprising assembling a response buffer at the smart card within which 
1 5 to marshal response parameters for the called API. 

40. A method for developing smart card applications according to claim 

39, wherein the smart card issues a response to the called API which, when received 
by the computer system is posted to the executing appHcation. 

20 

41. A proxy library comprising: 

a plurality of fields containing information regarding a number of smart card 
application program interfaces (API), wherein the proxy library provides a 
parameter definition of a smart card application program interface (API) when 
25 accessed by control logic upon receiving a remote procedure call (RPC) from an 
application executing on a computer system, the proxy library enabling the 
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application executing on the computer system to utilize the resources of the coupled 
smart card without having to download the application to the smart card, 

42. A proxy library according to claim 41, wherein the proxy library is 
5 located on a storage medium within the computer system. 

43. A proxy library according to claim 41, wherein the proxy library is 
accessible by a plurality of computers through a communication network. 

10 
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